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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This specification provides the necessary information to develop a MS for support of GPRS within the digital cellular 
telecommunications system. 

The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS it will then be republished by ETSI with an identifying change of release 
date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 indicates GSM Release 1997 of Phase 2+ 

y the third digit is incremented when editorial only changes have been incorporated in the specification; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 



Introduction 



This document contains the necessary information to develop a MS for support of GPRS. It is up to the manufacturer 
how to implement the various functions but this specification and existing GSM 07.01, 07.02, and 07.03 shall be 
followed where applicable. 

It is the intention that this document shall remain as the specification to develop a MS for support of GPRS and its text 
includes references to GSM standards. 
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1 . Scope 



The GSM PLMN supports a wide range of voice and non- voice services in the same network. In order to enable non- 
voice traffic in the GSM PLMN there is a need to connect various kinds of terminal equipments to the Mobile Station 
(MS). This Specification describes the functionality of a MS supporting GPRS, including the protocols and signalling 
needed to support the first phase of GPRS, as defined in GSM 02.60 and 03.60 (packet based services). 



Normative references 



References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 
acronyms".. 

[2] GSM 02.02: "Digital cellular telecommunication system (Phase 2+); Bearer Services (BS) 

supported by a GSM Public Land Mobile Network (PLMN)". 

[3] GSM 02.60: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS); Service Description Stage 1". 

[4] GSM 03.02: "Digital cellular telecommunication system (Phase 2+); Network architecture". 

[5] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and 

identification". 

[6] GSM 03.10: "Digital cellular telecommunication system (Phase 2+); GSM Pubhc Land Mobile 

Network (PLMN) connection types". 

[7] GSM 03.22: "Digital cellular telecommunications system (Phase 2+); Functions related to Mobile 

Station (MS) in idle mode and group receive mode". 

[8] GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of the 

Short Message Service (SMS); Point-to-Point (PP)". 

[9] GSM 03.60: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS) Service Description Stage 2". 

[10] GSM 04.02: "Digital cellular telecommunication system (Phase 2+); GSM PubHc Land Mobile 

Network (PLMN) access reference configuration". 

[II] GSM 04.07: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 
signalling layer 3; General aspects". 

[12] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

layer 3 specification". 
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[13] GSM 04.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control / 
Medium Access Control (RLC/MAC) protocol". 

[14] GSM 04.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Logical Link Control (LLC)". 

[15] GSM 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Subnetwork Dependent Convergence Protocol (SNDCP)". 

[16] GSM 07.07: "Digital cellular telecommunication system (Phase 2+); AT command set for GSM 

Mobile Equipment (ME)". 

[17] GSM 09.61: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS); Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and 
Packet Data Networks (PDN)". 

[18] CCITT Recommendation E.164: "Numbering plan for the ISDN era". 

[19] CCITT Recommendation V.42 bis: "Data communication over the telephone network - Data 

compression procedures for data circuit-terminating equipment (DCE) using error correction 
procedures". 

[20] CCITT Recommendation X.3: "Packet assembly disassembly facility (PAD) in a public data 

network". 

[21] CCITT Recommendation X.25: "Interface between data terminal equipment (DTE) and data 

circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

[22] CCITT Recommendation X.28: "DTE / DCE interface for a start-stop mode data terminal 

equipment accessing the packet assembly / disassembly facility (PAD) in a public data network 
situated in the same country". 

[23] CCITT Recommendation X.29: "Procedures for the exchange of control information and user data 

between a packet assembly / disassembly (PAD) facility and a packet mode DTE or another PAD". 

[24] CCITT Recommendation X.75: "Packet-switched signalling system between public networks 

providing data transmission services". 

[25] CCITT Recommendation X. 1 2 1 : "International Numbering Plan for Public Data Networks" . 

[26] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6). 

[27] IETF RFC 791 (1981): "Internet Protocol" (STD 5). 

[28] IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5). 

[29] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7). 

[30] ITU-T Recommendation V.250 (ex V.25ter): "Serial asynchronous automatic dialling and control". 



3. Definitions abbreviations and symbols 
3.1 Definitions 

Refer to: GSM 02.60 [2]. 

In GSM 02.02 the bearer services are described. The general network configuration is described in GSM 03.02 and the 
GSM PLMN access reference configuration is defined in GSM 04.02. The various connection types used in the GSM 
PLMN are presented in GSM 03.10. Terminology used in this Specification is presented in GSM 01.04. For support of 
data services between GSM PLMN and other networks see GSM 09-series of Specifications. 
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3.2 



Abbreviations 



For the purposes of this specification the following abbreviations apply: 

APN Access Point Name 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

GTP GPRS Tunnelling Protocol 

HDLC High Level Data Link Control 

ICMP Internet Control Message Protocol 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

LA Location Area 

LAPB Link Access Protocol Balanced 

LCP Link Control Protocol 

LLC Logical Link Control 

MAC Medium Access Control 

ME Mobile Equipment 

MS Mobile Station 

MT Mobile Termination 

NCP Network Control Protocol 

PAD Packet Assembler/Disassembler 

PDN Packet Data Network 

PDP Packet Data Protocol , e.g., IP or X.25 

PDU Protocol Data Unit 

PSPDN Packet Switched Public Data Network 

PTM Point To Multipoint 

PTP Point To Point 

PVC Permanent Virtual Circuit 

RA Routing Area 

SGSN Serving GPRS Support Node 

SNDCP SubNetwork Dependent Convergence Protocol 

TE Terminal Equipment 

TCP Transmission Control Protocol 

UDP User Datagram Protocol 



3.3 Symbols 

For the purposes of this specification the following Symbols apply: 



Gb 
Gi 
Gn 
Gp 

Gs 
R 

Um 



Interface between an SGSN and a BSC. 

Reference point between GPRS and an external packet data network. 

Interface between two GSNs within the same PLMN. 

Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS 

network services across areas served by the co-operating GPRS PLMNs. 

Interface between an SGSN and MSC. 

The reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 

The interface between the MS and the GPRS fixed network part. The Um interface is the GPRS 

network interface for providing packet data services over the radio to the MS. The MT part of the 

MS is used to access the GPRS services through this interface. 
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Access reference configuration 



Figure 1 shows the relationship between the MS, its terminal equipment and the GSM network in the overall GPRS 
environment. 



R 



reference point ^ . 



Gi 

reference point 




GSM GPRS 

network 1 



MS 




GSM GPRS 

network 2 



Figure 1 :GPRS Access Interfaces and Reference Points 



5. Functions to support data services 

The main functions of the MT to support data services are: 
- physical connection at the reference point R; 
flow control between TE and MT; 
mapping of user signalling to/from the GPRS bearer; 

support of data integrity between the terminal equipment and the GPRS bearer; 
functions to support character based data; 
functions to support packet based data; 



Interface to GPRS Bearer Services 



The following figure 2: Transmission Plane shows the relationship of the GPRS Bearer terminating at the SNDCP layer 
to the rest of the GPRS environment. It is shown for reference purposes only and detailed information can be found in 
GSM 03.60. 
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NOTE: In the SGSN and GGSN UDP is mandatory. TCP is optional but recommended for X.25 services. 

Figure 2:GPRS Transmission Plane 



7. 



Functions common to all configurations of the GPRS 
MS. 



7.1 



Mobile Classes 



Three GPRS MS classes are identified: Class A, B, and C. These classes are described in GSM 02.60. 



7.2 Physical Interface 



The physical interface between the TE and the MT may conform to CCITT/ITU-T V.24/V.28, or to IrDA IrPHY 
physical standard specification, or to PCMCIA PC-Card electrical specification. All signal levels and their operation 
shall be as specified in GSM 07.01, 07.02, and 07.03. This shall not preclude any new developments such as USB 
(Universal Serial Bus). 



7.3 Terminal context procedures 



This subclause describes the relationships for GPRS Attach and Detach, and PDP Context Activation and Deactivation. 
The procedures for these functions are described in GSM 03.60. 

7.3.1 GPRS Attach 

The GPRS Attach shall be performed prior to activating a PDP context. The GPRS Attach may be performed 
automatically or manually depending on the manufacturer's implementation and configuration. 

7.3.2 GPRS Detach 

The GPRS Detach may be performed automatically or manually depending on the manufacturer' s implementation and 
configuration. The following cases are valid: 

if the connection between the TE and MT is broken then the MT may perform the GPRS Detach procedure; 

if the network originates a GPRS Detach the MT may inform the TE; 

if the radio connection is broken then the MT may inform the TE; 

if the TE deactivates the last PDP context then the MT may perform the GPRS Detach procedure. 
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7.3.3 Mobile Originated PDP Context Activation 

The PDP Context Activation may be performed automatically or manually depending on the manufacturer' s 
implementation and configuration. Depending on the manufacturer's implementation and configuration, 0, 1, or more 
PDP contexts can be active simultaneously. 

7.3.4 Networl< Requested PDP Context Activation. 

The network can request a GPRS attached MS to activate a specific PDP context. 

7.3.5 PDP Context Deactivation 

The PDP Deactivation may be performed automatically or manually depending on the manufacturer' s implementation 
and configuration. The following cases are valid: 

if the connection between the MT and theTE is broken then the MT may perform the PDP Context Deactivation 
procedure. 

if the radio connection is broken then the MT may inform the TE. 

if the TE deactivates the last PDP context then the MT may perform the GPRS Detach procedure. 

7.3.6 PDP context related parameters 

It shall be possible to enquire and/or set the following parameters: 

Requested Quality of Service. 

(this includes the peak bit rate, the mean bit rate, the delay requirements, the service precedence, and the 

reliability level) 

Data Compression on or off. 

TCP/IP Header Compression on or off. 

- PDP address 

- PDP type 

- Access Point Name (APN) 



8 X.25 Based Services 



This clause describes the use of X.25 based services over the GPRS bearer. Two services are specified at the R 
reference point - 

1) Character mode (specified in ITU-T X.3, X.28, X.29) with the triple X PAD in the MT. 

2) Packet mode (specified in ITU-T X.25). 

NOTE: In order to maintain consistency within GSM specifications, the term TE is used when referring to what 

CCITT/ITU-T X.25 calls a DTE. Exceptionally, in text quoted from an ITU-T Recommendation, the term 
DTE is retained. 8.1 X.25 Character mode (triple X PAD) service 

This mode is an asynchronous character based service allowing the application to set up a single connection using the 
CCITT/ITU-T X.28 / X.29 procedures. This supports both mobile originate and mobile terminate calls. The MT 
terminates the X.25 packet layer and provides a triple X PAD function. 
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TE 
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Char 
Async 



LI 



Rref 



MT 
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?AD 



X 



X.28 



Char 
Async 



LI 



25 DTE 



GPRS Bearer 



GGSN 



NOTE: X.25 in the above diagram refers to X.25 pacl<et layer. 

Figure 3: Character (Triple X PAD) mode 
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8.1 



PAD Parameters 



The following table lists the minimum set of X.3 parameters that shall be implemented. A full range is specified in the 
CCITT/ITU-T X series documents and those parameters not implemented shall be fixed to their defined defaults. 

Table 4: Table of Minimum X.3 Parameters 



Parameter 
Number 


Description 


Default 
Value 


Valid 
Values 


Value/Function 


1 


PAD Recall Character 


1 




1 
32-36 


(None) 

DLE 

Binary representation of decimal value 


2 


Echo 







1 


Off 
On 


3 


Data Forwarding 
Character 


2 




1 

2 

4 

8 

16 
32 
64 


(on 128th data byte) 

A-Z, a-z, 0-9 

CR 

ESC, BEL, ENQ, ACK 

DEL, CAN, DC2 

ETX, EOT 

HT, LF, VT, FF 

All characters between NUL & US not listed 

above 


4 


Delay Timer 







1-255 


Disabled 

Period of TXD cct inactivity before data 
forwarded (1/20 of a second). The minimum 
time-out is 0.5s. Any value of parameter 4 
between 1 & 10 will default to 0.5s. 


5 


Flow Control from Pad 
(to DTE) 







1 


None 
XON/XOFF 


6 


Service Signals 


5 




1 

5 


Disabled 

Enabled, excluding prompt 

Enabled, including prompt 


7 


Action on Break 


8 


8 


PAD escapes from data transfer state 


11 


Data Rate 


13 


2 

3 

4 

6 

12 

13 

14 


300 bps 

1200 bps 

600 bps 

150 bps 

2400 bps 

4800 bps 

9600 bps 

Other values can be implemented as long as 

they conform to the CCITT/ITU-T 

specifications. 


12 


Flow Control to Pad 
(from DTE) 







1 


None 
XON/OFF 


13 


Line Feed insertion 







1 


None 

LF inserted after CR to DTE 


15 


Character Deletion 







1 


Disabled 
Enabled 



Although not CCITT/ITU-T defined, to be able to specify either X.28 or X.29 modes a Parameter can be used as 
follows. 

For X.28 mode parameter shall be set to 0. 

For the four X.29 variants available, each with a corresponding protocol identifier, the paramater value is set as listed 
below. The identifier octet is supplied with the call request packet when setting up a call. 
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Value 


Description 


Protocol Identifier Octet 


2 


CCITT use 


00000001 


3 


National use 


Olxxxxxx 


4 


International User Bodies 


lOxxxxxx 


5 


DTE - DTE use 


llxxxxxx 



X - this digit may be represented by either a 1 or (to be specified in Recommendation X.244). 

8.1 .1 Example mapping of functions between tine R reference point and 
tine GPRS bearer 

The following example illustrates the case when the PAD functionality is used in the MT. In PAD mode only one PDP 
context can be activated per R reference point. 



■E R 


MT Um 


1. AT commar 


d 












2. GPRS Attach 








3. PDP Context Activation 


4. AT responsf 

















NOTE: The 2 ended arrows Indicate an exchange of or more messages. 

Figure 4: PAD Service 

1) The TE issues an AT command to activate PAD mode. 

2) If the MS is not yet GPRS attached, the MT performs the GPRS Attach procedure as described in GSM 03.60. 

3) The MT performs the PDP Context Activation as described in GSM 03.60. 

4) The MT sends an AT response to the TE. On positive AT response the PAD prompt is issued. 



8.2 



X.25 Packet mode service 



This mode offers a packet based service allowing the application to set up one or more virtual calls using the 
CCITT/ITU-T X.25 procedures. The maximum permitted number of concurrent virtual calls is implementation 
dependent. Both mobile originate and mobile terminate calls are supported. The MT performs a relay function for X.25 
layer 3 which is terminated in the TE. The layer 2 protocol at the R reference point is terminated in the TE and the MT. 

Depending on the application, the TE may or may not incorporate a triple X PAD function. 
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PAD 
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X.25 DTE 












LAPB 

or 

other L2 


GPRS Bearer 




LAPB 

or 

other L2 










L1 


L1 

























NOTE: X.25 in the above diagram refers to the X.25 packet layer. 

The "other L2" could be GSM 07.10 or a manufacturer's defined layer 2 

Figure 5: Packet mode 

8.2.1 Layer 1 and Layer 2 options 

This subclause describes standardized layers 1 and 2 which may be used for the TE-MT interface. As an alternative, the 
multiplexing protocol specified in GSM 07.10 or a manufacturer's defined layers 1 and 2 may be used providing they 
meet the requirements for carrying X.25 layer 3 frames over the R reference point. 

8.2.1 .1 Synchronous serial interface 

For TEs with a synchronous serial port - 

Layer 1 is synchronous X.21 orX.21bis (V.24/V.28). 
Layer 2 is LAP B (X.25 L2) based on bit-oriented HDLC. 

8.2.1 .2 Asynchronous serial interface 

For TEs with an asynchronous serial port - 
Layer 1 is asynchronous V.24/V.28. 
Layer 2 is LAP B (X.25 L2) based on character-oriented HDLC. 



8.2.1.3 



Synchronous and asynchronous (dual mode) interface 



For TEs with a serial port that can operate in both synchronous and asynchronous modes the following mechanism may 
be used where the interface supports AT commands. The interface starts in asynchronous mode and AT commands may 
be used to configure the MT. When configuration is complete, the interface switches to synchronous mode and X.25 
starts up in the usual way. Setting Data Terminal Ready (circuit 108/2) to off is a protocol independent way of returning 
to asynchronous mode. Alternatively, the closing down of LAP B could be used as the signal. 

8.2.2 Example mappings of functions between the R reference point and 
the GPRS bearer 

The minimum requirement is that the MT shall be GPRS-attached and the X.25 context activated whilst an X.25 virtual 
call is in progress. Any extension to this requirement depends on whether the MT implements any other GPRS- 
supported services (e.g. SMS) which might require that the MT remains GPRS-attached even when there is no X.25 
virtual call in progress. 
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The following subclauses describe only the X.25 requirements. These actions may be filtered by the requirements of any 
other GPRS-supported service. For example, if a GPRS-only MT also supports SMS, a request for 'disconnection' of the 
X.25 service would result in a deactivation of the X.25 context but not a GPRS-detach. 

8.2.2.1 Standardized X.25 TE 

This case applies to TEs which implement only the X.25 procedures, i.e. they have no support for AT commands. The 
layer 1 and 2 options described in subclause 8.2.1.1 and 8.2.1.2 apply. 

Because of the different implementations of X.25 procedures in existing DTEs, attach/detach and activate/deactivate 
may need to be controlled at layer 1, 2 or 3 of the X.25 interface. Whilst it is always possible to use layer 3 control, this 
requires the most complete implementation of the X.25 protocol stack in the MT. Control at a lower layer may result in 
a simpler implementation. The procedures for connection and disconnection at all three layers are described in 
CCITT/ITU-T X.25. 

In all cases it may be desirable to incorporate a timer to delay the deactivate/detach procedures in order to avoid 
excessive changes of the activation and attachment states in the course of a number of consecutive calls. 

NOTE: The activation and deactivation of an X.25 context to carry packets over GPRS is analogous to setting up and 
clearing a switched ISDN B channel connection to carry them over an ISDN. The call control mapping procedures used 
in the ISDN case are described in detail in ITU-T X.31 clause 7.3 (layer 1) and appendix I (layers 2 and 3). 

8.2.2.1.1 Layer 1 control 

This applies to X.25 DTEs which disconnect at the physical layer when no virtual calls are in progress. The TE and MT 
signal to one another by using V.24 or X.21 control signals. 

From TE - 

Physical layer connect received by MT -> attach, activate 

Physical layer disconnect received by MT -> deactivate, detach 

From network - 

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual 
call will be signalled by the receipt at the MT of a Request PDP Context Activation message. The MT signals 
this to the TE by using V.24 or X.21 control signalling and, if successful, -> attach, activate. 

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT 
performing a physical layer disconnect. 

8.2.2.1.2 Layer 2 control 

This applies to X.25 DTEs which keep layer 1 active but disconnect at the data link layer when no virtual calls are in 
progress. The TE and MT signal to one another by starting and stopping the data link layer protocol. 

From TE - 

Data link layer set-up received by MT -> attach, activate 

Data link layer disconnect received by MT -> deactivate, detach 

From network - 

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual 
call will be signalled by the receipt at the MT of a Request PDP Context Activation message. The MT signals 
this to the TE by attempting to start the data link layer and, if successful, -> attach, activate. 

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT 
performing a data link layer disconnect. 
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8.2.2.1.3 Layer 3 control 

This applies to X.25 DTEs which keep layers 1 and 2 active when no virtual calls are in progress. 

From TE - 

Call Request packet received by the MT -> attach, activate 

(Action is taken only if there are no X.25 virtual calls already in progress) 

Clear Confirmation packet received by the MT from the TE -> deactivate, detach 
(Action is taken only if there are no more X.25 virtual calls in progress.) 

From network - 

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual 
call will be signalled by the receipt at the MT of a Request PDP Context Activation message. Following 
activation by the MT, an X.25 Call Request packet will be received from the network. 

Clear Confirmation packet received by the MT from the network -> deactivate, detach 
(Action is taken only if there are no more X.25 virtual calls in progress.) 

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT 
clearing any outstanding X.25 virtual calls. 

The above refer only to normal clearing situations. An actual implementation shall take into account exceptional 
conditions such as the receipt of a Clear Request packet from the TE but no acknowledging Clear Confirmation from the 
network. 

8.2.2.2 X.25 TE with support for AT commands 

This case applies to TEs which implement AT commands in addition to supporting X.25 procedures. The layer 1 and 2 
options described in subclauses 8.2.1.2 and 8.2.1.3 apply. 

The TE sends GPRS AT commands to configure the MT, followed by a command to switch the interface into packet 
mode and start X.25. A mode of operation may be supported which provides compatibility with existing modem dial 
procedures. 



9. IP Based Services 

All protocols that are supported by the underlying IP protocol are applicable in the GPRS environment. However there 
may be some limitations due to the RF environment. 

The IP protocol can be run over various underlying protocols as shown in the following figure. 
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Figure 6: IP Based Services 

PPP is a widely supported protocol in numerous operating systems and this alleviates the need for any GPRS specific 
protocol at the TE. PPP at the MT shall comply with the following specifications IETF STD 51 (RFC 1661, RFC 1662), 
RFC 1570, RFC 1989, and RFC 1332. The Domain Name Server information shall be delivered as defined in RFC 
1877. The delivery of vendor-specific packets and options shall conform to RFC 2153. 

As an alternative to PPP, an L2 protocol can be used which is defined as a manufacturer's operating system dependent 
protocol capable of carrying IP frames over the R reference point. 

9.1 Example mapping of functions between the R reference 
point and the GPRS bearer for IP over PPP 

The following example illustrates the case when the IP over PPP functionality is used in the MT. The example does not 
include all the details of PPP, but only describes the logical operation of PPP connection establishment, host 
authentication and IP configuration. In PPP mode only one PDP context can be activated per R reference point. 
However, it is possible for a PCMCIA card to support multiple virtual interfaces at R reference points. 
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Figure 7: IP Over PPP Based Service 

1) The TE issues AT commands to set up parameters and enter PPP mode (refer to subclause on AT commands for 
further details). 

2) The MT sends AT responses to the TE. 

3) The PPP protocol in the TE sends a LCP Configure-Request. This command is to establish a PPP link between 
the TE and the MT. 

4) The MT returns LCP Configure- Ack to the TE to confirm that the PPP link has been established. The MT might 
previously have sent a LCP Configure-Nak in order to reject some options proposed by the TE. This in turn 
might have triggered a retransmission of the LCP Configure-Request with different options. 

5) The PPP protocol in the MT sends a LCP Configure-Request in order to negotiate for the authentication protocol 
used for authentication of the host TE towards the MT. The MT shall primarily negotiate for CHAP, and as a 
second choice for PAP. 

6) The TE returns a LCP Configure-Ack to the MT to confirm the use of the specified authentication protocol. The 
MT might previously have sent a LCP Configure-Nak in order to reject the protocol proposed by the TE. This in 
turn might have triggered a retransmission of the LCP Configure-Request with different options. 

7) If the negotiated authentication protocol is either of CHAP or PAP, the TE authenticates itself towards the MT by 
means of that protocol. The MT stores the necessary authentication data and sends a locally generated positive 
acknowledgement of the authentication to the TE. If none of the protocols is supported by the host TE no 
authentication shall be performed. Refer to GSM 09.61 for further details on the authentication. 

8) The PPP protocol in the TE sends to the MT a NCP Configure-Request. This command activates the IP protocol. 

9) If the MS is not yet GPRS attached, the MT performs the GPRS Attach procedure as described in GSM 03.60. 

10) The MT performs a PDP Context Activation as described in GSM 03.60. IP configuration parameters may be 
carried between the MT and the network in PDP Context Activation messages. 
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1 l)The MT acknowledges to the PPP protocol in the TE that the IP protocol is now activated by sending a NCP 
Configure- Ack command. Before sending a NCP Configure- Ack, the MT might previously have sent a NCP 
Configure-Nak in order to reject some IP parameters proposed by the TE. This in turn might have triggered a 
retransmission of the NCP Configure-Request with different parameter values. NCP Configure- Ack may also 
carry IP protocol related parameters such as dynamic IP address to the TE. The MT shall also pass name server 
information to the TE if the TE has requested for it and if this information is provided by the GGSN. Other 
packet types and options may optionally be delivered. 



10. AT commands 

This clause defines commands that a TE may use to control a GPRS MT via a non-multiplexed character-stream 
interface. This places certain limitations on the functionality of the interface. For example, it is not possible for the MT 
to send control information to the TE or for the TE to send commands to the MT whilst the interface is in the V.250 
online data state unless the layer 2 protocol itself supports this feature. However, a manufacturer-specific escape 
mechanism may be provided to enable the TE to switch the MT into the V.250 online command state. The use of a 
multiplexed interface, for example that specified in GSM 07.10, is not considered here. 

It is anticipated that GPRS MTs will vary widely in functionality. At one extreme, a class A MT might support multiple 
PDP types as well as circuit switched data, and use multiple external networks and QoS profiles. At the other extreme a 
class C MT might support only a single PDP type using a single external network, and rely on the HLR to contain the 
context definition. 

A comprehensive set of AT commands is defined to provide the flexibility needed by the more complex MT. It is 
designed to be expandable to accommodate new PDP types and interface protocols, merely by defining new values for 
many of the parameters. Multiple contexts may be activated if the interface link-layer protocol is able to support them. 
The commands use the extended information and error message capabilities described in GSM 07.07. The GPRS- 
specific commands, and extensions to existing GSM AT commands and error codes are described in subclauses 10.2 and 
10.3 respectively. 

For MTs of intermediate complexity, most commands have simplified forms where certain parameters may be omitted. 

For the simplest MTs, and for backwards compatibility with existing communications software, it is possible to control 
access to the GPRS using existing modem-compatible commands. A special dial-string syntax is defined for use with the 
D command. This "modem compatible" mode of operation is described in subclause 10.4. 

Subclause 10.5 contains examples of command sequences for a number of applications. 

1 0.1 General on AT commands 

1 0.1 .1 Interaction of AT commands, GPRS management and PDPs 

State machines may be used to describe the behaviour of - 

AT commands (ITU-T V.250). 

GPRS PDP context management (GSM 03.60). 

PDP startup, data transfer and termination (Packet Data Protocol specifications). 

The layer 2 protocol (if any) used across the TE-MT interface (layer 2 protocol specifications). 

This subclause does not attempt to describe in detail how these state machines interact but rather to give some general 
guidance on their relationships. 

10.1.1.1 AT commands and responses 

AT commands may be issued and responses received by the TE only when the TE and MT are in V.250 command state. 
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The possibility of suspending the PDP and/or layer 2 protocol and entering V.250 online command state is not 
considered here. Neither is the use of a multiplexed interface where the PDP and the AT commands use separate logical 
channels. 

1 0.1 .1 .2 PDP and layer 2 protocol operation 

The PDP (across the TE-MT interface) may startup, transfer data and terminate only when the TE and MT are in V.250 
online data state. It may be necessary to startup a layer 2 protocol across the interface before starting the PDP. The PDP 
startup procedure may provide information needed for the PDP context activation procedure (see 10.1.1.3.2). 

10.1.1.3 GPRS management 

A particular PDP may be used to transfer data only when a context must be active for that PDP. Before a context can be 
activated, the MT must be attached to the GPRS network. 

In order to provide flexibility and support a variety of types of GPRS MT and PDP, AT commands are provided which 
give the TE explicit control over attachment and detachment (+CGATT), and context activation and deactivation 
(+CGACT). These allow the TE to retain control of, and receive status information from, the MT after these actions 
have been performed. 

10.1.1.3.1 GPRS attachment 

The MT may be attached and detached using the +CGATT command. However, it may not be necessary to actually use 
the command since attachment may occur - 

on power up or reset; 

when an attempt is made to activate a context either explicitly (+CGACT) or as a result of a PDP startup procedure; 

when the mobile class is changed (+CGCLASS). 

Similarly, detachment may occur - 

as a result of a PDP termination procedure (if no other GPRS services are active); 

when the mobile class is changed (+CGCLASS). 

10.1.1.3.2 PDP context activation 

Certain information must be provided to the network in order for a context activation attempt to be successful. The TE 
may provide some of this information to the MT during the PDP startup procedure rather than through AT command 
procedures. In this case the context activation cannot be initiated by the +CGACT command but rather on receipt of the 
appropriate information during the PDP startup. 

1 0.1 .2 Use of default context parameter values 

The activate context request message sent by the MT to the network contains a number of parameters whose values can 
usefully be set by the TE. Under certain circumstances the values for some or all of the parameters need not be provided 
by the TE, either via AT commands or the PDP startup procedure. The storage of context information in the SIM is not 
considered in this specification. Rules concerning what values shall be sent by the MT to the network under various 
circumstances are given in 03.60. 

One particular rule that is designed to simplify operation in modem compatibility mode is that if there is only one PDP 
context subscription in the HLR then all of PDP type, PDP address and APN may be omitted. 

10.1.2.1 PDP type 

This may be omitted: 

when the MT supports only one PDP type (it will be provided by the MT); 
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or according to the rules given in 03.60. 

10.1.2.2 PDP address (of the MS) 

This shall be omitted when: 

a dynamic address is required; 

or according to the rules given in 03.60. 

1 0.1 .2.3 Access Point Name 

This may be omitted: 

according to the rules given in 03.60. 

10.1.2.4 QoS Requested 

This may be omitted when: 

the default subscribed QoS is acceptable. 

1 0.1 .2.5 PDP Configuration Options 

These shall be omitted: 

when none are required for the PDP concerned; 
or according to the rules given for the PDP. 
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1 0.2 Commands specific to MTs supporting the GPRS 
1 0.2.1 Define PDP Context -i-CGDCONT 

Table 2: +CGDCONT parameter command syntax 



Command 


Possible response(s) 


+CGDCONT=[<cid> [,<PDP_type> [,<APN> 
[,<PDP_addr> [,<d_comp> [,<h_comp> 
[,<pdl> [,...[,pdN]]]]]]]]] 


OK 
ERROR 


+CGDCONT? 


+CGDCONT: <cid>, <PDP_type>, 
<APN>, <PDP_addr>, <data_comp>, 
<head_comp> [ , <pdl > [,...[, pdN ] ] ] 
[<CR><LF>+CGDCONT: <cid>, <PDP_type>, 
<APN>, <PDP_addr>, <data_comp>, 
<head_comp> [ , <pdl > [,...[, pdN ] ] ] 
[...]] 


+CGDCONT=? 


+CGDCONT : (range of supported <cid>s) , 
<PDP_type>, , , (Hst of supported <d_comp>s) , 
(list of supported <h_comp>s) [ , (Hst of supported 
<pdl>s) [,...[, (hst of supported <pdN>s) ] ] ] 
[<CR><LF>+CGDCONT: (range of supported <cid>s) , 
<PDP_type>, , , (Hst of supported <d_comp>s) , 
(Hst of supported <h_comp>s) [ , (Hst of supported 
<pdl>s) [,...[, (Hst of supported <pdN>s) ] ] ] 
[...]] 



Description 
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The set command specifies PDP context parameter values for a PDP context identified by the (local) context 
identification parameter, <cid>. The number of PDP contexts that may be in a defined state at the same time is given 
by the range returned by the test command. 

A special form of the set command, +CGDCONT= <cid> causes the values for context number <cid> to become 
undefined. 

The read command returns the current settings for each defined context. 

The test command returns values supported as a compound value. If the MT supports several PDP types, 
<PDP_type>, the parameter value ranges for each <PDP_type> are returned on a separate line. 

Defined values 

<cid>: (PDP Context Identifier) a numeric parameter which specifies a particular PDP context definition. The 
parameter is local to the TE-MT interface and is used in other PDP context-related commands. The range of 
permitted values (minimum value = 1) is returned by the test form of the command. 

<PDP_type>: (Packet Data Protocol type) a string parameter which specifies the type of packet data protocol 

X25 ITU-T/CCITT X.25 layer 3 
IP Internet Protocol (IETF STD 5) 

<APN>: (Access Point Name) a string parameter which is a logical name that is used to select the GGSN or the 
external packet data network. 

If the value is null or omitted, then the subscription value will be requested. 

<PDP_address>: a string parameter that identifies the MT in the address space applicable to the PDP. 

If the value is null or omitted, then a value may be provided by the TE during the PDP startup procedure or, 
failing that, a dynamic address will be requested. 

The read form of the command will continue to return the null string even if an address has been allocated during 
the PDP startup procedure. The allocated address may be read using the +CGPADDR command. 

<d_comp>: a numeric parameter that controls PDP data compression 

- off (default if value is omitted) 

1 - on 

Other values are reserved. 

<h_comp>: a numeric parameter that controls PDP header compression 

- off (default if value is omitted) 

1 - on 

Other values are reserved. 

NOTE. At present only one data compression algorithm (V.42bis) is provided in SNDCP. If and when other 
algorithms become available, a command will be provided to select one or more of these. 

<pdl>, ... <pdN>: zero to N string parameters whose meanings are specific to the <PDP_type> 

At present none is defined. 

Implementation 

Mandatory unless only a single subscribed context is supported. 

1 0.2.2 Quality of Service Profile (Requested) +CGQREQ 

Table 3: +CGQREQ parameter command syntax 



Command 


Possible Response(s) 


+CGQREQ=[<cid> [,<precedence > [,<delay> 


OK 
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[,<reliability.> [,<peak> [,<mean>]]]]]] 


ERROR 


+CGQREQ? 


+CGQREQ: <cid>, <precedence >, <delay>, 
<reliability>, <peak>, <mean> 
[<CR><LF>+CGQREQ: <cid>, <precedence >, 
<delay>, <reliability . >, <peak>, <mean> 


+CGQREQ=? 


+CGQREQ: <PDP_type>, (list of supported 
<precedence>s) , (list of supported 
<delay>s), (list of supported 
<reliability>s) , (list of supported 
<peak>s), (list of supported <mean>s) 
[<CR><LF>+CGQREQ: <PDP_type>, (list of 
supported <precedence>s) , (list of 
supported <delay>s), (list of supported 
<reliability>s) , (list of supported 
<peak>s), (list of supported <mean>s) 



Description 

This command allows the TE to specify a Quality of Service Profile that is used when the MT sends an Activate PDP 
Context Request message to the network. 

The set command specifies a profile for the context identified by the (local) context identification parameter, <cid>. 
Since this is the same parameter that is used in the +CGDCONT command, the +CGQREQ command is effectively an 
extension to the +CGDCONT command. The QoS profile consists of a number of parameters, each of which may be set 
to a separate value. 

A special form of the set command, +CGQREQ= <cid> causes the requested profile for context number <cid> to 
become undefined. 

The read command returns the current settings for each defined context. 

The test command returns values supported as a compound value. If the MT supports several PDP types, the parameter 
value ranges for each PDP type are returned on a separate line. 

Defined values 

<cid>: a numeric parameter which specifies a particular PDP context definition (see +CGDCONT command). 
The following parameters are defined in GSM 03.60 - 

<precedence>: a numeric parameter which specifies the precedence class 

<delay>: a numeric parameter which specifies the delay class 

<reliability>: a numeric parameter which specifies the reliability class 

<peak>: a numeric parameter which specifies the peak throughput class 

<mean>: a numeric parameter which specifies the mean throughput class 
If a value is omitted for a particular class then the value is considered to be unspecified. 
Implementation 
Optional. If the command is not implemented then all the values are considered to be unspecified. 



ETSI 



GSM 07.60 version 6.1.1 Release 1997 



25 



TS101 356V6.1.1 (1998-07) 



1 0.2.3 Quality of Service Profile (Minimum acceptable) -i-CGQMIN 

Table 4: +CGQMIN parameter command syntax 



Command 


Possible Response(s) 


+CGQMIN=[<cid> [,<precedence > [,<delay> 
[,<reliability.> [,<peak> [,<mean>]]]]]] 


OK 
ERROR 


+CGQMIN? 


+CGQMIN: <cid>, <precedence >, <delay>, 
<reliability>, <peak>, <mean> 
[<CR><LF>+CGQMIN: <cid>, <precedence >, 
<delay>, <reliability . >, <peak>, <mean> 


+CGQMIN=? 


+CGQMIN: <PDP_type>, (list of supported 
<precedence>s) , (list of supported 
<delay>s), (list of supported 
<reliability>s) , (list of supported 
<peak>s), (list of supported <mean>s) 
[<CR><LF>+CGQMIN: <PDP_type>, (list of 
supported <precedence>s) , (list of 
supported <delay>s), (list of supported 
<reliability>s) , (list of supported 
<peak>s), (list of supported <mean>s) 



Description 

This command allows the TE to specify a minimum acceptable profile which is checked by the MT against the 
negotiated profile returned in the Activate PDP Context Accept message. 

The set command specifies a profile for the context identified by the (local) context identification parameter, <cid>. 
Since this is the same parameter that is used in the +CGDCONT command, the +CGQMIN command is effectively an 
extension to the +CGDCONT command. The QoS profile consists of a number of parameters, each of which may be set 
to a separate value. 

A special form of the set command, +CGQMIN= <cid> causes the minimum acceptable profile for context number 
<cid> to become undefined. In this case no check is made against the negotiated profile. 

The read command returns the current settings for each defined context. 

The test command returns values supported as a compound value. If the MT supports several PDP types, the parameter 
value ranges for each PDP type are returned on a separate line. 

Defined values 

<cid>: a numeric parameter which specifies a particular PDP context definition (see +CGDCONT command). 
The following parameters are defined in GSM 03.60 - 

<precedence>: a numeric parameter which specifies the precedence class 

<delay>: a numeric parameter which specifies the delay class 

<reliability>: a numeric parameter which specifies the reliability class 

<peak>: a numeric parameter which specifies the peak throughput class 

<mean>: a numeric parameter which specifies the mean throughput class 
If a value is omitted for a particular class then this class is not checked. 
Implementation 
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Optional. If the command is not implemented then no check is made against the negotiated profile. 

1 0.2.4 GPRS attach or detach +CGATT 

Table 5: +CGATT action command syntax 



Command 


Possible Response(s) 


+CGATT= [<state>] 


OK 
ERROR 


+CGATT? 


+CGATT: <state> 


+CGATT=? 


+CGATT: (list of supported <state>s) 



Description 

The execution command is used to attach the MX to, or detach the MT from, the GPRS service. After the command has 
completed, the MT remains in V.250 command state. If the MT is already in the requested state, the command is 
ignored and the OK response is returned. If the requested state cannot be achieved, an ERROR or +CME ERROR 
response is returned. Extended error responses (enabled by the +CMEE command) are listed in subclause 10.3.1. 

Any active PDP contexts will be automatically deactivated when the attachment state changes to detached. 

The read command returns the current GPRS service state. 

The test command is used for requesting information on the supported GPRS service states. 

NOTE: This command has the characteristics of both the V.250 action and parameter commands. Hence it has the 
read form in addition to the execution/set and test forms. 

Defined Values 

<state>: indicates the state of GPRS attachment 

- detached 

1 - attached 

Other values are reserved and will result in an ERROR response to the execution command. 

Implementation 

Optional. 

1 0.2.5 PDP context activate or deactivate +CGACT 

Table 6: +CGACT action command syntax 



Command 


Possible Response(s) 


+CGACT=[<state> [ , <cid> [ , <cid> [ , ...] ] ] ] 


OK 
ERROR 


+CGACT? 


+CGACT: <cid>, <state> 
[<CR><LF>+CGACT: <cid>, <state> 


+CGACT=? 


+CGACT: (list of supported <state>s) 



Description 

The execution command is used to activate or deactivate the specified PDP context (s). After the command has 
completed, the MT remains in V.250 command state. If any PDP context is already in the requested state, the state for 
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that context remains unchanged. If the requested state for any specified context cannot be achieved, an ERROR or 
+CME ERROR response is returned. Extended error responses (enabled by the +CMEE command) are Hsted in 
subclause 10.3. 1. If the MT is not GPRS attached when the activation form of the command is executed, the MT first 
performs a GPRS attach and them attempts to activate the specified contexts. If the attach fails then the MT responds 
with ERROR or, if extended error responses are enabled, with the appropriate failure-to-attach error message. 

If no <cid>s are specified the activation form of the command activates all defined contexts. 

If no <cid>s are specified the deactivation form of the command deactivates all active contexts. 

The read command returns the current activation states for all the defined PDP contexts. 

The test command is used for requesting information on the supported PDP context activation states. 

NOTE. This command has the characteristics of both the V.250 action and parameter commands. Hence it has the 
read form in addition to the execution/set and test forms. 

Defined Values 

<state>: indicates the state of PDP context activation 

- deactivated 

1 - activated 

Other values are reserved and will result in an ERROR response to the execution command. 

<cid>: a numeric parameter which specifies a particular PDP context definition (see +CGDCONT 
command).+CGDCONT 

Implementation 

Optional. 
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1 0.2.6 Enter data state +CGDATA 

Table 7: +CGDATA action command syntax 



Command 


Possible Response(s) 


+CGDATA=[<L2P> ,[<cid> [,<cid> [,...]]]] 


CONNECT 
ERROR 


+CGDATA=? 


+CGDATA: (list of supported <L2P>s) 



Description 

The execution command causes the MT to perform whatever actions are necessary to establish communication between 
the TE and the network using one or more GPRS PDP types. This may include performing a GPRS attach and one or 
more PDP context activations. If the <L2P> parameter value is unacceptable to the MT, the MT shall return an ERROR 
or +CME ERROR response. Otherwise, the MT issues the intermediate result code CONNECT and enters V.250 online 
data state. 

Commands following +CGDATA command in the AT command line shall not be processed by the MT. 

The detailed behaviour after the online data state has been entered is dependent on the PDP type. It is described briefly 
in clauses 8 (for X.25) and 9 (for IP) and in more detail in GSM 09.61 and the specifications for the relevant PDPs. 
GPRS attachment and PDP context activation procedures may take place prior to or during the PDP startup if they have 
not already been performed using the +CGATT and +CGACT commands. 

If context activation takes place during the PDP startup, one or more <cid>s may be specified in order to provide the 
values needed for the context activation request(s). 

During the PDP startup procedure the MT may have access to some or all of the following information - 
The MT may have a priori knowledge, for example, it may implement only one PDP type. 
The command may have provided an <L2P> parameter value. 
The TE may provide one or both of PDP type and PDP address to the MT in the PDP startup. 

If any of this information is in conflict, the command will fail. 

If one or more <cid> is given then an attempt shall be made to identify an appropriate context definition by matching 
any PDP type and PDP address present in this information, with the PDP type and PDP address in each of the specified 
context definitions (in the order in which their <cid>s appear in the command) as follows - 

The PDP type must match exactly. 

The PDP addresses are considered to match if they are identical or if either or both addresses are unspecified. For 
example, a PPP NCP request specifying PDP type = IP and no PDP address would cause the MT to search 
through the specified context definitions for one with PDP type = IP and any PDP address. 

The context shall be activated using the matched value for PDP type and a static PDP address if available, together with 
the other information found in the PDP context definition. If a static PDP address is not available then a dynamic 
address is requested. 

If no <cid> is given or if there is no matching context definition, the MT will attempt to activate the context with 
whatever information is available to the MT. The other context parameters will be set to their default values. 

If the activation is successful, data transfer may proceed. 

After data transfer is complete, and the layer 2 protocol termination procedure has completed successfully, the V.250 
command state is re-entered and the MT returns the final result code OK 

In the event of an erroneous termination or a failure to startup, the V.250 command state is re-entered and the MT 
returns the final result code NO CARRIER or, if enabled, H-CME ERROR. Attach, activate and other errors may be 
reported. 
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The test command is used for requesting information on the supported layer 2 protocols. 

This command may be used in both normal and modem compatibility modes. 

Defined Values 

<L2P>: a string parameter that indicates the layer 2 protocol to be used between the TE and MT 

PPP Point-to-point protocol for a PDP such as IP 

PAD character stream for X.25 character (triple X PAD) mode 

X25 X.25 L2 (LAPB) for X.25 packet mode 

M-xxxx manufacturer-specific protocol (xxxx is an alphanumeric string) 

If the value is omitted, the layer 2 protocol is unspecified. Other values are reserved and will result in an ERROR 
response. 

<cid>: a numeric parameter which specifies a particular PDP context definition (see H-CGDCONT command). 

Implementation 

Optional if the D (dial) command can be used to specify GPRS operation. 

1 0.2.7 Show PDP address +CGPADDR 

Table 8:+CGPADDR action command syntax 



Command 


Possible response(s) 


+CGPADDR=[<c 
id> [,<cid> 


+CGPADDR: <cid>, <PDP_addr> 
[<CR><LF>+CGPADDR: <cid>, <PDP_addr> 
[...]] 


+CGPADDR=? 


+CGPADDR: (list of defined <cid>s) 



Description 

The execution command returns a list of PDP addresses for the specified context identifiers. 

The test command returns a list of defined <cid>s. 

Defined values 

<cid>: a numeric parameter which specifies a particular PDP context definition (see H-CGDCONT command). 
If no <cid> is specified, the addresses for all defined contexts are returned. 

<PDP_address>: a string that identifies the MT in the address space applicable to the PDP. The address may 
be static or dynamic. For a static address, it will be the one set by the H-CGDCONT command when the context 
was defined. For a dynamic address it will be the one assigned during the last PDP context activation that used 
the context definition referred to by <cid>. <PDP_address> is omitted if none is available. 

Implementation 

Optional. 
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1 0.2.8 Automatic response to a network request for PDP context activation 
+CGAUTO 

Table 9: +CGAUTO parameter command syntax 



Command 


Possible response(s) 


+CGAUTO=[<n>] 


OK 
ERROR 


+CGAUTO? 


+CGAUTO: <n> 


+CGAUTO=? 


+CGAUTO: (list of supported <n>s) 



Description 

The set command disables or enables an automatic positive response (auto-answer) to the receipt of a Request PDP 
Context Activation message from the network. It also provides control over the use of the V.250 basic commands 'SO', 
'A and 'H' for handling network requests for PDP context activation. The setting does not affect the issuing of the 
unsolicited result code RING or +CRING. 

The test command returns the values of <n> supported by the MT as a compound value. 

When the +CGAUTO=l command is received, the MT shall attempt to perform a GPRS attach if it is not already 
attached. Failure will result in ERROR or, if enabled, +CME ERROR being returned to the TE. Subsequently, the MT 
will announce a network request for PDP context activation by issuing the unsolicited result code RING or +CRING to 
the TE, followed by the intermediate result code CONNECT. The MT then enters V.250 online data state and follows 
the same procedure as it would after having received a +CGANS=1 with no <L2P> or <cid> values specified. 

NOTE. The +CGAUTO=0 command does not perform an automatic GPRS detach. 

Defined values 

<n>: 

turn off automatic response (circuit switched as in GSM 07.07) 

1 turn on automatic response (circuit switched as in GSM 07.07) 

2 modem compatibility mode, GPRS only 

3 modem compatibility mode, GPRS and circuit switched calls (default) 

For <n> = or 1 GPRS network requests are manually accepted or rejected by the +CGANS command. The 'SO', 'A' and 
'H' commands control only circuit switched calls according to GSM 07.07. 

For <n> = 2, automatic acceptance of GPRS network requests is controlled by the 'SO' command. Manual control uses 
the 'A' and 'H' commands, respectively, to accept and reject GPRS requests. (+CGANS may also be used.) Incoming 
circuit switched calls can be neither manually nor automatically answered. 

For <n> = 3, automatic acceptance of both GPRS network requests and incoming circuit switched calls is controlled by 
the 'SO' command. Manual control uses the 'A' and 'H' commands, respectively, to accept and reject GPRS requests. 
(+CGANS may also be used.) Circuit switched calls are handled according to GSM 07.07. 

Implementation 

Optional. If not implemented, the MT shall behave according to the case of <n> = 3. 
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1 0.2.9 Manual response to a network request for PDP context activation 
+CGANS 

Table 10: +CGANS action command syntax 



Command 


Possible response(s) 


+CGANS=[<response>, 
[<L2P> ,[<cid>]]] 


OK 
ERROR 


+CGANS=? 


+CGANS: (list of supported 
<response>s), (list of supported 

<L2P>s) 



Description 

The execution command requests the MT to respond to a network request for GPRS PDP context activation which has 
been signalled to the TE by the RING or +CRING: unsolicited result code. The <response> parameter allows the TE 
to accept or reject the request. 

If <response> is 0, the request is rejected and the MT returns OK to the TE. 

If <response> is 1, the following procedure is followed by the MT. 

Commands following the +CGANS command in the AT command line shall not be processed by the MT. 

If the <L2P> parameter value is unacceptable to the MT, the MT shall return an ERROR or +CME ERROR response. 
Otherwise, the MT issues the intermediate result code CONNECT and enters V.250 online data state. 

The detailed behaviour after the online data state has been entered is dependent on the PDP type. It is described briefly 
in clauses 8 (for X.25) and 9 (for IP) and in more detail in GSM 09.61 and the specifications for the relevant PDPs. PDP 
context activation procedures shall take place prior to or during the PDP startup. 

One or more <cid>s may be specified in order to provide the values needed for the context activation request. 

During the PDP startup procedure the MT has the PDP type and the PDP address provided by the network in the 
Request PDP Context Activation message. The MT may also have some or all of the following information - 

The MT may have a priori knowledge, for example, it may implement only one PDP type. 

The command may have provided an <L2P> parameter value. 

The TE may provide one or both of PDP type and PDP address to the MT in the PDP startup. 

If any of this information is in conflict, the command will fail. 

If one or more <cid> is given then an attempt shall be made to identify an appropriate context definition by matching the 
PDP type and PDP address in the network request with the PDP type and PDP address in each of the specified context 
definitions (in the order in which their <cid>s appear in the command) as follows - 

The PDP type must match exactly. 

The PDP addresses are considered to match if they are identical or if the address in the context definition is 
unspecified. 

The context shall be activated using the values for PDP type and PDP address provided by the network, together with 
the other information found in the PDP context definition. An APN may or may not re required, depending on the 
application. 

If no <cid> is given or if there is no matching context definition, the MT will attempt to activate the context using the 
values for PDP type and PDP address provided by the network, together with any other relevant information known to 
the MT. The other context parameters will be set to their default values. 

If the activation is successful, data transfer may proceed. 
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After data transfer is complete, and the layer 2 protocol termination procedure has completed successfully, the V.250 
command state is re-entered and the MT returns the final result code OK 

In the event of an erroneous termination or a failure to startup, the V.250 command state is re-entered and the MT 
returns the final result code NO CARRIER or, if enabled, H-CME ERROR. Attach, activate and other errors may be 
reported. It is also an error to issue the H-CGANS command when there is no outstanding network request. 

NOTE: This is not the same as if the MT issues a H-CGDATA (or H-CGACT) command after receiving a H-CRING 
unsolicited result code. A H-CGDATA (or H-CGACT) does not command the MT to acknowledge the 
network request but rather to make a new request for context activation. The network request would be 
ignored. 

The test command returns the values of <response> and <L2P> supported by the MT as compound values. 

This command may be used in both normal and modem compatibility modes. 

Defined values 

<response>: is a numeric parameter which specifies how the request should be responded to. 

reject the request 

1 accept and request that the PDP context be activated 

If <response> is omitted it is assumed to be 0. Other values are reserved and will result in the ERROR response. 

<L2P>: a string parameter which indicates the layer 2 protocol to be used (see +CGDATA command). 

<cid>: a numeric parameter which specifies a particular PDP context definition (see +CGDCONT command). 
Implementation 
Optional. 

1 0.2.1 GPRS mobile station class +CGCLASS 

Table 1 1 : +CGCLASS parameter command syntax 



Command 


Possible Response(s) 


+CGCLASS= [<class>] 


OK 
ERROR 


-hCGCLASS? 


+CGCLASS: <class> 


-hCGCLASS=? 


+CGCLASS: (Hst of supported <class>s) 



Description 

The set command is used to set the MT to operate according to the specified GPRS mobile class. If the requested class is 
not supported, an ERROR or +CME ERROR response is returned. Extended error responses (enabled by the +CMEE 
command) are listed in subclause 10.3.1. 

The read command returns the current GPRS mobile class. The value returned may indicate a lower class than the last 
value set since the network can downgrade the class. 

The test command is used for requesting information on the supported GPRS mobile classes. It returns the classes that 
may currently be used. Due to a network downgrading, these may form a subset of those actually supported by the MT. 
The implemented set shall be returned when the MT is detached from the GPRS network. 
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Defined Values 

<class>: a string parameter which indicates the GPRS mobile class (in descending order of functionality) 
A class A (highest) 
B class B 

C class C in GPRS and circuit switched alternate mode 
CGclass C in GPRS only mode 
CC class C in circuit switched only mode (lowest) 

If the MT is GPRS attached when the set command is issued with a<class> = CC specified, a detach request shall be 
sent to the network. 

Other values are reserved and will result in an ERROR response to the set command. 

Implementation 

Optional. 

1 0.2.1 1 Configure local triple-X PAD parameters +CGCLPAD 

Table 12: +CGCLPAD parameter command syntax 



Command 


Possible Response(s) 


+CGCLPAD=[<parm>, <value>] 


OK 
ERROR 


+CGCLPAD? 


+CGCLPAD: <parm>, <value> 
[<CR><LF>+CGCLPAD: <parm>, <value>> 


+CGCLPAD=? 


+CGCLPAD: <parm>, (list of supported 

<value>s) 

[<CR><LF>+CGCLPAD: <parm>, (list of 

supported <value>s) 



Description 

The set command sets the value of a specified X.3 PAD parameter in the local PAD. A minimum set of parameters to be 
supported is listed in table 4 (subclause 8.1.1). 

The read command returns, one per line, the value of each of the supported parameters. 

The test command returns, one per line, the permitted range of values for each of the supported parameters. 

Defined values 

<parm>: a numeric parameter which specifies the X.3 parameter to be configured 

<value>: a numeric parameter which specifies the value to which the X.3 parameter is to be set 

If <value> is omitted for a particular class then <parm> is set to the X.3-defined default, if any. 

Implementation 

Optional. 
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1 0.2.1 2 GPRS event reporting +CGEREP 

Table 13: +CGEREP parameter command syntax 



Command 


Possible response(s) 


+CGEREP= [ <mode> [ , <bf r> ] ] 


OK 
ERROR 


+CGEREP? 


+CGEREP : <mode>, <bfr> 


+CGEREP=? 


+CGEREP : (list of supported <mode>s) , (list of supported 

<bfr>s) 



Description 

Set command enables or disables sending of unsolicited result codes, +CGEV : XXX from MT to TE in the case of 
certain events occurring in the GPRS MT or the network. <mode> controls the processing of unsolicited result codes 
specified within this command. <bf r> controls the effect on buffered codes when <mode> 1 or 2 is entered. If a 
setting is not supported by the MT, ERROR or +CME ERROR : is returned. 

Read command returns the current mode and buffer settings 

Test command returns the modes and buffer settings supported by the MT as compound values. 

Defined values 

<mode>: 

buffer unsolicited result codes in the MT; if MT result code buffer is full, the oldest ones can be discarded. No 
codes are forwarded to the TE. 

1 discard unsolicited result codes when MT-TE link is reserved (e.g. in on-line data mode); otherwise forward 
them directly to the TE 

2 buffer unsolicited result codes in the MT when MT-TE link is reserved (e.g. in on-line data mode) and flush them 
to the TE when MT-TE Unk becomes available; otherwise forward them directly to the TE 

<bfr>: 

MT buffer of unsolicited result codes defined within this command is cleared when <mode> 1 or 2 is entered 

1 MT buffer of unsolicited result codes defined within this command is flushed to the TE when <mode> 1 or 2 is 
entered (OK response shall be given before flushing the codes) 

Defined events 

The following unsolicited result codes and the corresponding events are defined - 

+CGEV: REJECT <PDP_type>, <PDP_addr> 

A network request for PDP context activation occurred when the MT was unable to report it to the TE with a 
H-CRING unsolicited result code and was automatically rejected. 

+CGEV: NW REACT <PDP_type>, <PDP_addr>, [<cid>] 

The network has requested a context reactivation. The <cid> that was used to reactivate the context is provided 
if known to the MT. 

+CGEV: NW DEACT <PDP_type>, <PDP_addr>, [<cid>] 

The network has forced a context deactivation. The <cid> that was used to activate the context is provided if 
known to the MT. 
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+CGEV: ME DEACT <PDP_type>, <PDP_addr>, [<cid>] 

The mobile equipment has forced a context deactivation. The <cid> that was used to activate the context is 
provided if known to the MT. 

+CGEV: NW DETACH 

The network has forced a GPRS detach. This impHes that all active contexts have been deactivated. These are not 
reported separately. 

+CGEV: ME DETACH 

The mobile equipment has forced a GPRS detach. This implies that all active contexts have been deactivated. 
These are not reported separately. 

+CGEV: NW CLASS <class> 

The network has forced a change of MS class. The highest available class is reported (see +CGCLASS). 

+CGEV: ME CLASS <class> 

The mobile equipment has forced a change of MS class. The highest available class is reported (see 
+CGCLASS). 

Implementation 

Optional. 

1 0.3 Extensions to existing GSIVI AT commands and result codes 

These commands are described in GSM 07.07. This subclause extends their use to MTs supporting the GPRS. 

1 0.3.1 Report IVIobile Equipment error h-CIVIEE 

This command disables or enables the use of the result code +CME ERROR : <err> as an indication of an error 
relating to the functionality of the MT. When enabled, MT related errors cause +CME ERROR : <err> final result 
code instead of the normal ERROR final result code. ERROR is returned normally when the error is related to invalid 
syntax or parameters. The format of <err> can be either numeric or verbose. 

Additional <err> values defined for GPRS -related errors are given below. 

Implementation 

Mandatory for numeric format codes applicable to the implemented GPRS command set. 

1 0.3.1 .1 Errors related to a failure to perform an Attach 

Numeric Text 

103 (#3) Illegal MS 

106 (#6) Illegal ME 

107 (#7) GPRS services not allowed 

111 (#11) PLMN not allowed 

112 (#12) Location area not allowed 

113 (#13) Roaming not allowed in this location area 

(Values in parentheses are GSM 04.08 cause codes.) 
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1 0.3.1 .2 Errors related to a failure to Activate a Context 

Numeric Text 

132 (#32) service option not supported 

133 (#33) requested service option not subscribed 

134 (#34) service option temporarily out of order 

149 PDP authentication failure 

(Values in parentheses are GSM 04.08 cause codes.) 

10.3.1.3 Other errors 

Numeric Text 

150 invalid mobile class 

1 0.3.2 Extended error report +CEER 

This command causes the MT to return one or more lines of information text, determined by the MT manufacturer, 
which should offer the user of the MT an extended report of the reason for the most recent of a number of specified 
events. The following GPRS-specific events shall be added to the list in 07.07. 

- the last unsuccessful GPRS attach or PDP context activation 

- the last GPRS detach or PDP context deactivation. 
Implementation 

Optional. 

1 0.3.3 Cellular result codes +CRC 

This command controls whether or not the MT should use the extended format for indicating network requested PDP 
context activation. When enabled, the receipt of a Request PDP Context Activation message by the MT from the 
network is indicated to the TE with the unsolicited result code +CRING : <type> instead of the normal RING. If the 
MT is unable to announce to the TE the network's request (for example it is in V.250 online data state) the MT shall 
reject the request. No corresponding unsolicited result code shall be issued when the MT returns to a command state. 

An additional value for <type> is defined for GPRS - 

GPRS <PDP_type>, <PDP_addr> [,<L2P>] 

<PDP_type> and <PDP_addr> are as defined in the Define PDP Context (+CGDCONT) command. 

The optional <L2P> proposes a layer 2 protocol to use between the MT and the TE. It is defined in the Enter GPRS 
Data Mode (+CGDATA) command. 



10.4 Modem compatibility 



This subclause describes how existing AT commands, designed for use with a modem, may be used to control a GPRS 
MT. This is to provide backwards compatibility with existing communications software. For new applications it is 
recommended that the GPRS-specific commands, described in previous subclauses, be used. 

1 0.4.1 IVIT originated PDP context activation 

In this mode of operation, the MT behaves like an originating modem and accepts the normal V.250 commands 
associated with placing and clearing a call. If GPRS-specific configuration commands are required, they may be sent to 
the MT as part of the modem initialisation commands. 
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10.4.1.1 Request GPRS service 'D' 

Table 14: D command syntax 



Command 


Possible Response(s) 


D*<GPRS SC>[*[<called address>] 
[* [<L2P>] [* [<cid>] ] ] ]# 


CONNECT 
ERROR 



Description 

The V.250 'D' (Dial) command causes the MT to enter the V.250 online data state and, with the TE, to start the specified 
layer 2 protocol. The MT shall return CONNECT to confirm acceptance of the command prior to entering the V.250 
online data state. No further commands may follow on the AT command line. 

When the layer 2 protocol has terminated, either as a result of an orderly shut down of the PDP or an error, the MT shall 
enter V.250 command state and return the NO CARRIER final result code. 

If <L2P> and <cid> are supported, their usage shall be the same as in the +CGDCONT command. The +CGDCONT 
command may be used in the modem initialisation AT command string to set values for APN, QoS etc.. 

This command may be used in both normal and modem compatibility modes. 

Defined Values 

<GPRS_SC>: (GPRS Service Code) a digit string (value 99) which identifies a request to use the GPRS 

<called_address>: a digit string (see note) that specifies the address of a called party in the address space 
applicable to the PDP. 

<L2P>: a digit string (see note) which indicates the layer 2 protocol to be used (see +CGDATA command). 
Numeric equivalents to the alphanumeric values used by +CGDATA are: 

1 PPP 

2 PAD 

3 X25 
9yyyy M-xxxx 

Other values are reserved and will result in an ERROR response to the set command. 

<cid>: a digit string which specifies a particular PDP context definition (see +CGDCONT command). 

NOTE. The dial string conforms to the syntax specified in GSM 02.30. 

Implementation 

Optional if the +CGDATA command is supported. If the D command is provided, then support for 
<called_address>, <L2P> and <cid> are optional. If they are not supported but values are provided by the TE, 
the values shall be ignored and this shall not constitute an error. 

NOTE. V.250 (and certain communications software) does not permit arbitrary characters in the dial string. The 
<L2P> and <called_address> strings are therefore specified as containing digits (0-9) only. 

1 0.4.2 Network requested PDP context activation 

In this mode of operation, the MT behaves like an answering modem and accepts the normal V.250 commands 
associated with answering a call. If GPRS-specific configuration commands are required, they may be sent to the MT as 
part of the modem initialisation commands. 

The H-CGANS command is used to select modem compatibility mode. 
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1 0.4.2.1 Automatic response to a network request for PDP context activation 'SO' 

The V.250 'SO=n' (Automatic answer) command may be used to turn off (n=0) and on (n>0) the automatic response to a 
network request for a PDP context activation. 

When the 'SO=n' (n>0) command is received, the MT shall attempt to perform a GPRS attach if it is not already 
attached. Failure will result in ERROR being returned to the TE. Subsequently, the MT will announce a network 
request for PDP context activation by issuing the unsolicited result code RING to the TE, followed by the intermediate 
result code CONNECT. The MT then enters V.250 online data state and follows the same procedure as it would after 
having received a +CGANS=1 with no <L2P> or <cid> values specified. 

NOTE. The 'SO=n' (n=0) command does not perform an automatic GPRS detach. 

Implementation 

Optional. 

1 0.4.2.2 Manual acceptance of a network request for PDP context activation 'A' 

The V.250 'A' (Answer) command may be used to accept a network request for a PDP context activation announced by 
the unsolicited result code RING. The MT responds with CONNECT, enters V.250 online data state and follows the 
same procedure as it would after having received a +CGANS=1 with no <L2P> or <cid> values specified. It is an error 
to issue the 'A' command when there is no outstanding network request. 

Implementation 

Optional. 

1 0.4.2.3 Manual rejection of a network request for PDP context activation 'H' 

The V.250 'H' or 'HO' (On-hook) command may be used to reject a network request for PDP context activation 
announced by the unsolicited result code RING. The MT responds with OK. It is an error to issue the 'H' command 
when there is no outstanding network request. 

NOTE: This is an extension to the usage of the 'H' command that is described in ITU-T V.250. 

Implementation 

Optional. 

1 0.5 Example command sequences 
1 0.5.1 PPP in dial compatibility mode 
1 0.5.1 .1 Mobile initiated IP context activation 

In this mode of operation, the MT behaves like an originating modem and accepts the normal V.250 commands 
associated with placing and clearing a call to a dial-up PPP server. Although the procedures for setting up the IP context 
are initiated from the mobile end, IP-based sessions, for example the File Transfer Protocol (FTP), may be initiated from 
either end once the context is active. 

For this example it is assumed that 

- the user has subscribed to only one PDP context (of type IP) and therefore no context parameter values are needed, 

- the MT supports only PPP at the MT-TE interface and therefore no layer 2 protocol need be specified. 
A possible sequence of events is - 

The MT begins in V.250 command state. 
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TE -> MT: AT<GPRS-specific configuration commands, if required> 

MT -> TE: OK 

The TE sends a dial command requesting the GPRS. 

TE -> MT: ATD*99# 

MT -> TE CONNECT 

The MT enters V.250 online data state. 

TE starts up PPP (LCP exchange) - 
TE -> MT: LCP Configure-request 
MT -> TE: LCP Configure-ack 

PPP Authentication may take place (optional) 

TE starts up IP (NCPfor IP exchange) - 

TE -> MT: NCP(IP) Configure-request 

MT <-> network: MT performs the GPRS-attach procedure if the MT is not currently attached. 

MT <-> network: MT performs the IP context activation procedure. 

MT -> TE: NCP(IP) Configure-ack 

TE <-> MT< - > network: IP packets may now be transferred 

TE stops IP (optional) - 

TE-> MT: NCP(IP) Terminate-Request ) this 

MT<-> network: MT performs the IP context deactivation procedure ) is 

MT -> TE: NCP(IP) Terminate-Ack ) optional 

TE stops PPP - 

TE-> MT:LCP Terminate-Request 

MT <-> network: MT performs the IP context deactivation procedure if it has not already done so. 
MT <-> network: MT may perform the GPRS-detach procedure if no other GPRS services are active. 
MT -> TE: LCP Terminate-Ack 
The MT returns to V.250 command state and issues the final result code - 

MT -> TENO CARRIER 

The TE may recognise this as a return to V.250 command state. However, if it is using procedures intended for 
controlling modems, it may attempt to force a disconnect since in the modem case it cannot rely on the remote modem 
dropping the carrier. It will use some combination of - 

TE -> MT: TE drops circuit 108/2 (Data Terminal Ready) 

TE -> MT: escape sequence (e.g. +++) 

TE -> MT: ATH 

The MT should respond according to V.250 even if it is already in command state. 

If the connection is lost at any time, the MT shuts down PPP, returns to V.250 command state and issues the final result 
code - 

MT -> TENO CARRIER 

1 0.5.1 .2 Network requested IP context activation 

In this mode of operation, the MT behaves like an answering modem and accepts the normal V.250 commands 
associated with answering a call to a PPP server. Although the procedures for setting up the IP context are initiated from 
the network end, IP-based sessions, for example the File Transfer Protocol (FTP), may be initiated from either end once 
the context is active. 

Two example sequences of events are given, for the cases of automatic and manual answering - 

Case 1: automatic answering 

The MT begins in V.250 command state. 
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TE -> MT: AT<GPRS-specific configuration commands, if required > 

The TE sets automatic answering mode - 
TE -> MT: ATS0=1 

MT <- > network: MT performs the GPRS-attach procedure if the MT is not currently attached. 

Subsequently - 

network -> MT: Request PDF Context Activation message 
MT -> TE: RING 

The MT returns the intermediate result code - 

MT -> TE CONNECT 

- and enters V.250 online data state. 

The TE and MT perform the PPP and IP startup procedures which include the MT requesting the network to activate 
the IP context. 

Case 2: manual answering 

The MT begins in V.250 command state. 

TE -> MT: AT<GPRS-specific configuration commands, if required > 

The TE sets manual answering mode and requests a GPRS-attach (if necessary) - 

TE -> MT: ATSO=0 

TE -> MT: AT+CGATT= 1 

MT <- > network: MT performs the GPRS-attach procedure if the MT is not currently attached. 

network -> MT: Request PDP Context Activation message 

MT -> TE: RING 

The TE answers manually, - 

TE -> MT: ATA 

MT -> TE CONNECT 

- and enters V.250 online data state. 

The TE and MT perform the PPP and IP startup procedures which include the MT requesting the network to activate 
the IP context. 

or the TE rejects the connection - 

TE -> MT: ATH 

- and remains in V.250 command state 

1 0.5.2 MO X.25 virtual call using a triple-X PAD in dial compatibility mode 

This example shows how the <called_address> string may be used in the D command to make an X.25 call to a 
specified X. 121 address. 

The MT begins in V.250 command state. 

TE -> MT: AT<GPRS-specific configuration commands, if required> 

MT -> TE: OK 
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The TE sends a dial command requesting the GPRS to X.121 address 1234567890. 

TE->MT: ATD*99*1234567890# 

MT -> TE CONNECT 

The MT enters V.250 online data state, performs a GPRS attach if necessary and activates the X.25 context. It then 
automatically makes an X.25 call to the specified address, bypassing the PAD prompt. If the call is successful the MT 
responds with the PAD connect message - 

1234567890 COM 
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Annex A (Informative): 

Summary of AT commands for GPRS 

This informative annex lists the AT commands for GPRS that are described in this specification. 

Table A.I : Summary of AT commands for GPRS 



Command 


Subclause 
reference 


Description 


+CGACT 


10.2.5 


PDP context activate or deactivate 


+CGANS 


10.2.9 


IVIanual response to a network request for PDP 
context activation 


+CGATT 


10.2.4 


GPRS attacli or detach 


+CGAUTO 


10.2.8 


Automatic response to a networl< request for PDP 
context activation 


+CGCLASS 


10.2.10 


GPRS mobile station class 


+CGCLPAD 


10.2.11 


Configure local triple-X PAD parameters 


+CGDATA 


10.2.6 


Enter data state 


+CGDGONT 


10.2.1 


Define PDP context 


+CGEREP 


10.2.12 


Control unsolicited GPRS event reporting 


+GGPADDR 


10.2.7 


Show PDP address 


+CGQMIN 


10.2.3 


Quality of service profile (minimum acceptable) 


+CGQREQ 


10.2.2 


Quality of service profile (requested) 



Table A.2: Summary of GPRS Extensions to existing GSM AT commands 



Command 


Subclause 
reference 


Description 


+CEER 


10.3.2 


Extended error report (07.07 subclause 6.10) 


+CMEE 


10.3.1 


Report mobile equipment error (07.07 subclause 9.1) 


+CRC 


10.3.3 


Cellular result codes (07.07 subclause 6.1 1 ) 


+CREG 


10.3.4 


Network registration (07.07 subclause 7.2) 



Table A.3: Summary of AT commands for GPRS modem compatibility mode 



Command 


Subclause 
reference 


Description 


A 


10.4.2.2 


Answer - manual acceptance of a network request for 
PDP context activation 


D 


10.4.1.1 


Dial - request GPRS service 


H 


10.4.2.3 


On-hook - manual rejection of a network request for 
PDP context activation 


SO 


10.4.2.1 


Automatic answering control - automatic acceptance 
of a network request for PDP context activation 
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Annex B (informative): 
Document change history 
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SMG# 


CR 
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R97 
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